With the continuous progress of computer systems and the development of the Internet/intranet networks, each customer in the world is provided with an access to a wide range of information and services. As new applications are being discovered, the interaction between the Internet network, and more particularly the applications running into a service provider's computer and the user's computer located elsewhere in the network needs to be enhanced and developed.
Each computer is fitted today with an information access/management tool such as a browser, for instance Netscape manufactured by Netscape Inc., or Internet Explorer (manufactured by Microsoft Corporation of Redmond, Wash., U.S.A.) for providing an access to the Internet network and which constitutes the heart of the interaction between the latter and the user's machine. The interaction between the Internet applications and the user's machine is continuously enhanced by means of so-called plug-in code which enriches the browser, and provides the latter with new functions and new capabilities, for instance for taking benefit to the multimedia resources of the user's computer. Java script code is generally used for that purpose, and introduced in a HyperText Mark-up Language (HTML) page received by the browser. If the java script code refers to one plug-in code, which appears to be missing in the local machine, then the browser is controlled so as to download the missing reference and be enriched with the corresponding new functionality. For security reasons, any java script code downloaded through the Internet, as well as any java code, receives no direct access to the internal system resources of the user's machine. In no way the access to the hard disk directories is being allowed. As soon as the plug-in has been installed, the browser may load and run it in relation with the particularly HTML page being processed.
Although plug-in codes appears to be quite effective for adding new capabilities to a basic web browser, it is clear that they present a main drawback since they closely depend upon the operating system, and also the particular web browser which is run in the computer. This is a drawback since it increases the work of the Internet application designers who have thus to develop and maintain a wide set of plug-in libraries.
A second solution known in the art permits the development of software code appearing, in a certain extent, more independent on the particular operating system which is running in the user's computer. This is based on the use of java code which closely interacts with the web browser.
In the more recent versions of the known web browser, i.e. Netscape rel. 4 or Internet Explorer 4, there is provided a layer which allows the processing of signed objects (such as java code, javascript, active X for Internet Explorer . . . ) with an appropriate signature process which is different for each navigator. Those versions of the navigators become capable of receiving signed applets in the HTML pages, and thus expand and enhance the possibilities of the basic java code which is downloaded through the Internet network. As known by the skilled man, the java code is portable and can be executed in any machine, and particularly any browser provided that a java interpreter is therein available. However, the java code which is contained into an applet is not allowed to access to internal system resources of the user's computer (including accessing the directories on the hard disk, and initiating Internet connections etc . . . ), so as to prevent any malevolent intrusions in the user's machine. With the new versions of the browsers which were evoked above, the java code is given such a possibility to operate in an unprotected mode, when the latter however appears to be signed with an electronic certificate being granted by a certification authority, such as VeriSign, thus garanteing the origin of the java code. Further, prior to the execution of the signed applet code by the browser in an unprotected environment, the formal agreement of the user is requested.
In order to give access to the internal resources of the computer, such as audio capabilities and particularly the control of the recording mode and the adjustment of the recording level, some known solutions use a native code which is associated with the java code. The communication between that java code and the native code is achieved by means of an interface which is, in the case of Netscape for instance, the Java Native Interface included into that browser.
In this second known system, the native code is installed as follows. When the user wishes to receive one HTML page containing a visible reference to a java code—concretely the URL address and the reference of the file to be downloaded—the web browser fetches the latter at the specified addresses. The downloaded file is generally an aggregated file (generally archive jar or archive.cab in accordance with the particular web browser) containing all the files (.class) which are needed for the execution of the java code, and which is automatically downloaded by the web browser, and being executed in the virtual machine. In the case of a signed java code, a dialog box is displayed to the user in order to ask him to accept or reject the execution of the applet code with some extended capabilities. Once accepted, the java code is given the possibility to download an executable file, for instance a dynamic link library (dll), which provides the access to the desired audio resources. It should be noticed that all operations mentioned above, and the executable file, as well as the java code itself, still closely depend upon the communication interface between the applet and the native code, that is to say, finally, the web browser.
The second solution which was briefly evoked above, based on the use of applet interacting with the web browser, certainly improves the portability of the code compared to the known plug-in techniques. However, it is clear that even in that improvement, the native code and the applet still remains closely dependent on the particularly web browser which is being used, what obviously refrains the general portability of the java code when associated to a native code.
Therefore, when considering the known techniques, be it the plug-in or the java code interacting in close relationship with the web browser, it appears a need for improving more the situation and enhancing the independence of the java code with respect to the user's platform specification, as well as the independence of the native code with respect to the web browser.